大型語言模型在訓練完成後，對外部世界的知識便會受到訓練資料與時間範圍的限制。它可能知道大量公開知識，卻不認識你的公司規章、不知道最新版本的操作手冊，也看不到昨天才更新的合約範本。

然而，企業真正希望 AI 回答的，往往正是這些存在於模型訓練資料之外的私有知識。

RAG（Retrieval-Augmented Generation，檢索增強生成）就是為了解決這個落差而出現的架構。它不要求模型憑記憶回答，而是在模型產生答案之前，先從企業知識庫中找出相關資料，再把這些內容連同問題一起交給模型。

簡單來說，RAG 的核心概念就是：

先查資料，再回答問題。

什麼是 RAG？

RAG 的全名是 Retrieval-Augmented Generation，中文通常翻譯為「檢索增強生成」。

這個名稱可以拆成三個部分：

• Retrieval：檢索資料
• Augmentation：補充上下文
• Generation：生成答案

與一般的語言模型問答相比，RAG 在「生成答案」之前，多了一個主動搜尋資料的步驟。

我們可以用一個很熟悉的情境來理解：閉卷考試與開卷考試。

閉卷考試要求學生只靠記憶作答，這就像直接詢問大型語言模型。模型只能根據訓練時學到的知識，以及目前對話中提供的內容產生答案。

開卷考試則允許學生先查閱教材、筆記與參考資料，再整理成自己的回答。RAG 做的事情也是如此：它讓模型在回答前，先翻閱企業提供的文件。

模型仍然負責閱讀、理解與表達，但不再只能依賴過去的訓練記憶，而是可以根據當下查到的資料作答。

RAG 的三個基本步驟

一套基本的 RAG 系統，通常會經過 Retrieval、Augmentation 與 Generation 三個階段。

1. Retrieval｜根據問題檢索相關內容

當使用者提出問題後，系統會先分析問題的語意，再到知識庫中尋找最相關的文件片段。

例如，使用者問：

「員工出差申請需要提前幾天提出？」

系統不需要把所有人事規章都交給模型，而是會嘗試找出與「出差」、「申請」及「提前天數」最相關的內容。

在常見的 RAG 架構中，文件會事先被切割成多個較小的片段，也就是 Chunk。接著，系統會將使用者問題與文件片段轉換成向量，再比較彼此的語意相似程度。

這個階段會決定模型最後能看到哪些參考資料，因此檢索品質會直接影響回答品質。

如果系統找到了正確片段，模型就有機會回答正確；如果一開始取回了無關內容，後面的模型再強，也很難補救。

2. Augmentation｜把檢索結果加入上下文

找到相關文件片段後，系統會把這些內容與使用者原本的問題組合起來，形成一份新的 Prompt。

概念上可能像這樣：

請根據以下企業文件回答使用者問題。
如果文件中沒有答案，請明確說明無法確認，不要自行推測。

企業文件：
「出差申請應於出發日前五個工作天提出。」

使用者問題：
「員工出差申請需要提前幾天提出？」

這個步驟的作用，是把企業私有知識暫時放進模型當次回答所能看到的上下文中。

模型本身並沒有重新訓練，也沒有永久記住這份文件。它只是在這一次回答中，取得了額外的參考資料。

3. Generation｜根據資料產生答案

最後，模型根據取回的文件片段與使用者問題，整理出自然語言回答。

例如：

根據《差旅管理辦法》第 3 頁，員工出差申請應於出發日前五個工作天提出。

如果系統同時保留文件名稱、頁碼與段落位置，還能在回答中附上來源，讓使用者知道答案來自哪一份文件。

這使 RAG 的回答不只是「看起來合理」，而是有機會具備可追溯性。

RAG 解決了哪些企業問題？

RAG 主要回應企業 AI 應用中的三個核心痛點：模型看不到私有資料、企業資訊持續更新，以及答案需要來源佐證。

私有資料不在模型訓練資料中

大型語言模型通常不會看過企業內部的 Confluence、PDF、合約、流程文件與操作手冊。

如果沒有額外機制，模型自然無法回答與這些內容有關的問題。

RAG 不需要重新訓練模型，而是讓系統在回答時，從企業自己的知識庫取回相關內容。這使企業可以在不修改模型參數的情況下，補充內部知識。

企業資料持續更新

公司規章、產品資訊、流程文件與合約範本都可能持續變動。

如果把這些知識直接訓練進模型，每次文件更新都需要重新訓練或微調，不但成本高，也很難確保所有知識同步更新。

RAG 的做法則是更新知識庫中的文件。下一次使用者提問時，系統會重新搜尋最新內容，不需要重新訓練模型。

因此，RAG 特別適合處理需要持續維護與更新的企業知識。

回答需要來源依據

在一般聊天情境中，一個流暢合理的回答可能已經足夠。但在法務、合規、稽核、內控與正式營運流程中，只回答「AI 說是這樣」並沒有說服力。

使用者通常還需要知道：

• 答案來自哪一份文件
• 文件是哪一個版本
• 相關內容位於哪一頁
• 是否能回到原始段落確認
• 文件是否仍在有效期間內

RAG 可以在檢索時保留來源資訊，讓回答對應到實際文件。這也是它在企業場景中特別重要的原因。

Data Machi 實戰：Document Tool 如何運作？

在 Data Machi 中，Document Tool 就是 RAG 的具體實作之一。

當 Agent 收到一個與企業文件有關的問題時，Document Tool 會搜尋已經建立索引的 PDF 知識庫，找出語意最相關的文件片段，並回傳文件名稱、頁碼與實際內容。

模型取得這些資料後，再根據文件整理答案。

例如，使用者可能提出以下問題：

• 公司差旅報銷規範是什麼？
• 操作手冊第幾頁提到緊急停機流程？
• 最新版本的合約範本中，保密條款如何規定？
• 高優先級需求的判定標準是什麼？
• 某項作業流程需要經過哪些審核？

整體流程可以簡化成：

使用者問題：
「員工出差申請需要提前幾天送出？」

[Document Tool 搜尋知識庫]

命中結果：
文件：差旅管理辦法.pdf
頁碼：第 3 頁
內容：「出差申請應於出發日前五個工作天提出……」

[模型生成答案]

「根據《差旅管理辦法》第 3 頁，
員工出差申請應於出發日前五個工作天提出。」

在這個流程中，模型不是憑記憶回答，而是根據 Document Tool 取回的真實內容作答。

這也是 RAG 與一般聊天問答最關鍵的差異。

RAG 的價值不只是「找到答案」

RAG 最直接的功能是協助模型找到文件內容，但在企業環境中，它還有更深一層的價值。

首先，它讓企業知識不再只能依賴特定員工的記憶。當流程定義、規章與操作方式被整理進知識庫後，其他人也能透過自然語言快速查詢。

其次，RAG 可以降低資訊搜尋成本。使用者不需要知道答案藏在哪一份文件，也不必逐頁閱讀數十份 PDF，只需要描述問題，系統便會嘗試找出相關段落。

最後，RAG 為後續的 Tool Use 與 Agent 奠定基礎。當 AI 能找到並理解企業文件後，才有機會進一步根據規則執行操作、判斷流程或推動下一步任務。

因此，RAG 並不是企業 Agent 的終點，而是讓 AI 具備企業知識基礎的第一步。

RAG 的邊界：它不能解決什麼？

RAG 很重要，但它並不是萬能解法。

理解它的能力邊界，可以避免我們把所有企業 AI 問題都誤認為「做一套 RAG 就能解決」。

知識庫沒有資料，RAG 就找不到答案

如果企業知識庫中根本沒有相關文件，RAG 無法憑空創造正確答案。

例如，公司從未文件化某個審核流程，所有規則都只存在資深員工的經驗中，那麼 RAG 就沒有可檢索的來源。

此時真正需要解決的，不是模型問題，而是企業知識尚未被文件化。

文件品質會影響搜尋品質

即使文件存在，也不代表系統一定能找到正確內容。

如果 PDF 是模糊的掃描影像、文字解析錯誤、表格結構遺失，或文件切割方式不合理，檢索結果就可能受到影響。

常見問題包括：

• 掃描文件無法正確辨識文字
• 表格欄位被拆散
• 標題與內文分離
• 同一段規則被切成不同 Chunk
• 頁首頁尾干擾檢索
• 文件版本混在一起
• 過期規章與最新規章同時被搜尋到

因此，RAG 系統的品質不只取決於模型，也取決於文件解析、切割、索引與版本治理。

RAG 不會自動執行工作

RAG 的主要任務是「找資料」與「提供參考內容」。

它不代表系統自動具備以下能力：

• 查詢即時營運數據
• 執行統計計算
• 更新專案狀態
• 寄送 Email
• 建立待辦事項
• 呼叫外部 API
• 執行審核流程
• 追蹤後續行動

這些任務通常需要結合 Tool Use、Agent 與 Workflow。

可以把 RAG 想成讓 AI 學會查手冊，但查完手冊後，是否能真正完成工作，還需要其他工具與流程控制。

RAG 能讓 AI 找到知識，但不等於讓 AI 自動完成整段工作。

常見誤區：資料塞得越多越好嗎？

很多人在第一次建立 RAG 系統時，會有一個直覺：

「把整份文件全部交給模型，它不就什麼都知道了？」

但 RAG 的目標並不是把所有資料全部放進 Prompt，而是在使用者提出問題時，精準找出最相關的內容。

假設使用者只問差旅申請需要提前幾天，如果系統把整本 100 頁的員工手冊都交給模型，其中可能同時包含請假、薪資、考核、資安、福利與離職規定。

大量無關資訊不一定能幫助模型，反而可能稀釋真正重要的段落，使模型更難聚焦。

此外，把大量內容放入上下文還會帶來：

• 回應速度變慢
• 模型使用成本增加
• 重要資訊被埋在長文本中
• 不同規則互相干擾
• 超過模型上下文限制
• 更難追蹤答案究竟引用哪一段

因此，一套好的 RAG 系統追求的不是「全量」，而是「精準」。

在正確的時間，把正確的內容交給模型。

這也是後續 Chunk 切割、Embedding 與檢索策略如此重要的原因。

RAG 與 Fine-tuning 有什麼不同？

RAG 經常被拿來和 Fine-tuning（微調）比較，但兩者解決的是不同問題。

Fine-tuning：調整模型本身

Fine-tuning 會使用特定資料進一步訓練模型，修改模型內部參數。

它比較適合：

• 調整固定的回答風格
• 學習特定輸出格式
• 強化某一類任務能力
• 讓模型熟悉特定語言模式
• 提高分類或格式化任務的一致性

例如，希望模型固定用某種客服語氣回答，或將輸入內容轉換成特定 JSON 格式，就可能適合透過微調改善。

但如果目的是讓模型記住大量且持續更新的企業文件，微調通常不是最理想的做法。

原因包括：

• 訓練成本較高
• 文件更新後需要重新處理
• 很難確認模型記住哪些內容
• 回答不容易對應到具體來源
• 可能仍會產生錯誤或過期答案

RAG：在回答前補充外部知識

RAG 不修改模型參數，而是在每次回答時，從外部知識庫取回相關資料。

它比較適合：

• 企業內部文件查詢
• 持續更新的知識
• 需要來源引用的回答
• 大量文件搜尋
• 不同權限下的內容存取
• 需要保留文件版本的情境

RAG 的優點是知識庫可以隨時更新，而且回答可以追溯到原始文件。

兩者可以一起使用

RAG 與 Fine-tuning 並不是互斥選項。

成熟的企業 AI 系統可能同時使用：

• Fine-tuning：調整語氣、格式或特定任務行為
• RAG：補充即時、私有與可追溯的企業知識

例如，一個客服系統可以透過微調學習品牌語氣，再透過 RAG 查詢最新產品規格與退貨政策。

關鍵不是選擇哪一個比較高級，而是先理解目前要解決的是「模型行為問題」，還是「知識取得問題」。

如何判斷一個問題適不適合用 RAG？

RAG 特別適合以下情境：

• 答案存在企業文件中
• 文件數量很多，人工搜尋成本高
• 內容會持續更新
• 使用者不知道答案位於哪份文件
• 回答需要附上來源
• 不同使用者有不同文件權限
• 希望使用自然語言查詢知識庫

但如果任務主要是即時計算、更新系統或執行操作，單靠 RAG 可能不夠。

例如：

這張表也說明了，RAG 是企業 AI 系統的重要組件，但不是全部。

踩坑筆記：檢索成功，不代表回答一定正確

建立 RAG 系統後，很容易把注意力全部放在「有沒有搜尋到文件」，但檢索只是第一步。

即使系統取回了相關內容，模型仍可能：

• 忽略文件中的限制條件
• 混合不同版本的規則
• 過度延伸文件沒有說的內容
• 將範例當成正式規定
• 錯誤整合多個片段
• 沒有清楚區分事實與推論

因此，一套可靠的 RAG 系統還需要考慮：

• Prompt 是否要求模型只能根據來源回答
• 是否保留文件版本與有效日期
• 是否能顯示引用片段
• 找不到答案時是否會誠實說明
• 多份文件衝突時如何處理
• 回答產生後是否需要再次驗證
• 高風險問題是否需要人工確認

RAG 能降低模型憑空回答的機率，但不會自動消除所有幻覺。

真正可靠的設計，仍然需要搭配知識治理、來源管理與回答查核。

本日重點

今天只需要記住一件事：

RAG 不是重新訓練模型，而是在模型回答之前，先替它準備正確的參考資料。

它把 AI 從只能依賴訓練記憶的閉卷考試，轉變成可以先查閱企業文件的開卷考試。

一套基本的 RAG 系統會依序完成：

1. 根據問題搜尋相關文件
2. 取回最相關的內容片段
3. 將資料加入模型上下文
4. 根據資料產生回答
5. 保留文件名稱、頁碼或段落來源

RAG 可以協助企業解決私有資料不可見、資訊持續更新與答案缺乏來源等問題，但它不會自動完成即時查詢、系統操作與跨流程任務。

下一篇，我們會進一步拆解一份 PDF 如何一步步變成 AI 可以搜尋的知識庫，從文件解析、Chunk 切割、Embedding 向量化到索引建立，理解每一個步驟如何影響最終的搜尋品質。